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Description 

[0001 ] The present invention relates generally to data 
processing systems and, more particularly, to the use of 
logon certificates in a distributed system. 
[0002] Many conventional distributed systems do not 
support roaming users or roaming machines. A roaming 
user may wish to logon to the distributed system at do- 
mains other than his home domain. Similarly, roaming 
machines may wish to connect to the distributed system 
at sites outside of their home domain. The roaming user 
may use a roaming machine (e.g., a portable computer) 
to logon or may instead use a connected computer that 
is available at the logon site. The conventional systems 
that have supported such roaming users and machines 
have provided the support at the expense of efficiency 
and increased vulnerability. For example, certain con- 
ventional distributed systems store credentials informa- 
tion at a home domain of the user/machine. The creden- 
tials information stored at the home domain is examined 
when the user/machine tries to connect to the system 
at a different domain. The credentials information is ex- 
amined to determine whether the user/machine is per- 
mitted to connect to the distributed system. In order to 
facilitate roaming users and machines, these conven- 
tional distributed systems replicate the credentials infor- 
mation to each potential connection domain in the dis- 
tributed system (i.e., to each domain). 
[0003] This approach of replicating credentials across 
the system suffers from several drawbacks. First, the 
replication of the credentials information is costly and 
time-consuming. Second, the credentials information 
must be replicated frequently because credentials must 
be updated each time that the credentials information of 
any user or machine changes. Third, the replication of 
credentials may not be successful due to intermittent 
failure, and, thus, the proper credentials information 
may not reach all the targeted destinations in the dis- 
tributed system. Fourth, this approach poses a security 
threat because it provides more locations within the dis- 
tributed system that are susceptible to attack. 
[0004] GB-A-2 238 636 discloses an X Window secu- 
rity system, wherein an X Windows server system run- 
ning on a server and at least one host computer terminal 
is secured. Users are allowed to view only resources of 
the X Windows server system, the use of which has 
been specifically authorized to that user, and they are 
allowed to manipulate only resources of the X Windows 
server system, the use of which has been specifically 
authorized to that user. For each user of X Windows, a 
network-wide database holds the netname of the user, 
a public key, and a secret key encrypted with the user's 
password. A process that wishes to contact the server 
constructs a credential encrypted with the server's pub- 
lic key and containing the netname of the user and a 
verifier including a time stamp to prevent replays of the 
particular message. The verifier is encrypted using the 
user's secret key. The credential is checked against the 



network-wide database to determine the authorization 
of the particular user. 

[0005] Sead Muftic and Morris Sloman, "Security Ar- 
chitecture for Distributed Systems", Computer Commu- 
5 nications, vol. 17, no. 7, pages 492-500, July, 1994 de- 
scribes the concept of the security architecture for open 
distributed systems, which may be used for distributed 
applications which support a variety of security policies. 
The components of an open distributed system can be 
grouped into domains corresponding to organizations, 
networks or services etc. for the purposes of applying 
security policy. The X.509 certificate system is suggest- 
ed for inter-domain interaction. Inter-domain interaction, 
i.e. cross-domain authentication would be required 
when a user, registered and logged in one domain, re- 
quires services in another domain. 
[0006] It is the object of the invention to provide an 
improved method for authenticating and authorizing 
principals in a distributed system having computer re- 
sources and a facility for checking credentials informa- 
tion to authenticate principals and provide with authori- 
zation data. 

[0007] The above object is solved by the subject-mat- 
ter of the independent claims. 

[0008] Preferred embodiments are the subject-matter 
of the dependent claims. 

[0009] In accordance with a first aspect of the present 
invention, a method is practiced in the distributed sys- 
tem that has a facility for checking authorization and au- 
thentication information, typically referred to as creden- 
tials. In this method, a principal, such as a user or port- 
able computer, is provided with a secure package that 
holds certified credential information for the principal. 
The secure package may be encrypted and/or may in- 
clude a digital signature. The secure package may be 
provided to the principal by storing the secure package 
on a portable storage medium such as a floppy disk. Al- 
ternatively, the secure package may be provided to the 
principal by storing the secure package in the memory 
of a portable computer of the user. 
[0010] Once the principal has been provided with a 
secure package, the principal may send a request to lo- 
gon to the distributed system along with the certificate 
of credentials that is received by the distributed system. 
The secure package is accessed to enable the facility 
for checking credentials to determine whether the prin- 
cipal is authorized to connect to the distributed system. 
Where the principal is not authorized to connect to the 
distributed system, the principal's request to logon is de- 
nied. In contrast, where the principal is authorized to 
connect to the distributed system, the principal's request 
to connect is granted. 

[0011] In accordance with another aspect of the 
present invention, a distributed system is logically par- 
titioned into domains. Each user has an associated 
home domain. Authorization and authentication infor- 
mation about a user is encrypted to produce a block of 
encrypted credentials information. A digital signature is 
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attached to the encrypted credentials information at the 
home domain for the user. The digital signature is cre- 
ated using a private key for the home domain. A session 
key is received from the user and is used to encrypt the 
digital signature and the block of encrypted credentials 
information to produce a secure package. The secure 
package is provided to the user to enable the user to 
logon to the distributed system in a domain other than 
the home domain. 

[0012] The digital signature may be created by using 
a hash function to generate a hash value of the creden- 
tials information. An encryption key is selected to bulk 
encrypt the credentials information and then the hash 
value and the selected encryption key together are en- 
crypted using the private key of the home domain. The 
resulting product is the digital signature. 
[0013] In accordance with an additional aspect of the 
present invention, the method is practiced at a distrib- 
uted system that has a facility for verifying and validating 
the credentials information. A portable computer is pro- 
vided with a secure package that holds the credentials 
information for the computer. The portable computer is 
required to present the secure package when it wishes 
to connect to the distributed system in a domain other 
than its home domain. A facility for verifying and validat- 
ing the credentials information examines the credentials 
contained within the secure package to determine 
whether the computer is authorized to connect to the 
distributed system. If the portable computer is authenti- 
cated, it is permitted to connect to the distributed sys- 
tem. On the other hand, where the portable computer is 
not authenticated, the portable computer is not allowed 
to connect to the distributed system. 
[0014] In accordance with yet another aspect of the 
present invention, a method is practiced in the distribut- 
ed system that includes a plurality of computers and is 
logically partitioned into domains. Each computer in the 
distributed system has an associated home domain. A 
secure package is provided at the home domain of the 
computers. A secure package holds credentials infor- 
mation for the selected computer. A request is received 
from the selected computer to connect to the distributed 
system at a target domain that lies outside the home 
domain of the selected computer. The secure package 
is received from the selected computer and the creden- 
tials information contained within the secure package is 
examined to determine whether the selected computer 
is authorized to be connected to the distributed system 
at the target domain. 

[0015] In accordance with a further aspect of the 
present invention, a user is provided first with an option 
of logging on to the distributed system interactively. In 
this first option, a certificate of credentials is not re- 
quired. The user is also provided with a second option 
of logging on to the distributed system wherein a certif- 
icate of credentials is required. When a request to logon 
using the second option is received from a user, it must 
be accompanied by a certificate of credentials. The cer- 



tificate of credentials for the user is examined to deter- 
mine whether the user has sufficient credentials to be 
permitted to logon. Where it is determined that the user 
has sufficient credentials, the user is permitted to logon. 
5 On the other hand, where it is determined that the user 
lacks sufficient credentials, the user is prohibited from 
logging on. 

[0016] In accordance with a still further aspect of the 
present invention, a secure certificate of credentials is 
provided to a user to allow the user to logon to the dis- 
tributed system outside of the associated home domain 
for the user. A start time is established for the certificate 
of credentials that determines when this certificate be- 
comes valid. A time of expiration is established for the 
certificate of credentials. Once the time of expiration has 
passed, the user cannot logon using the expired certif- 
icate of credentials and any attempt by user to logon 
using the certificate of credentials to the distributed sys- 
tem is rejected by the distributed system. 
[0017] In accordance with an additional aspect of the 
present invention, when a request is received from a us- 
er to receive a secure certificate of credentials that will 
enable the user to logon to the distributed system out- 
side its associated home domain, the user is prompted 
for a password. The information indicative of the pass- 
word is encoded into the certificate of credentials before 
the certificate of credentials is issued to the user. The 
user is required to show knowledge of the password 
when attempting to logon using the certificate of creden- 
tials. 

[0018] In accordance with yet another aspect of the 
present invention, a certificate of credentials is issued 
to a user to enable the user to logon to the distributed 
system using the certificate of credentials to show that 
the user has proper and sufficient credentials. It is also 
possible to revoke the certificate of credentials so that 
the certificate of credentials may no longer be used to 
logon to the distributed system. 

[0019] Figure 1 is a block diagram of a distributed sys- 
tem that is suitable for practicing a preferred embodi- 
ment of the present invention. 

[0020] Figure 2A is a diagram illustrating the contents 
of a logon certificate in accordance with the preferred 
embodiment of the present invention. 
[0021] Figure 2B is a diagram illustrating in more de- 
tail the contents of the digitally signed and sealed cer- 
tificate of Figure 2A. 

[0022] Figure 3 is a flow chart illustrating the steps 
performed to obtain and use logon certificates in the pre- 
ferred embodiment of the present invention. 
[0023] Figure 4A is a flow chart illustrating the steps 
that are performed for a user to logon to the distributed 
system using a logon certificate in accordance with the 
preferred embodiment of the present invention. 
[0024] Figure 4B is a block diagram illustrating the in- 
teraction between major components of the distributed 
system during a logon in accordance with the preferred 
embodiment of the present invention. 
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[0025] The preferred embodiment of the present in- 
vention provides a secure and efficient approach for 
supporting roaming users and roaming machines in a 
distributed system environment. In particular, the pre- 
ferred embodiment of the present invention issues se- 
cure logon certificates to users/machines which may be 
later presented to the distributed system at locations 
other than the home domains of the users/machines to 
enable connection to the distributed system. The logon 
certificates encapsulate credentials information for the 
users/machines. Since each user/machine carries the 
credentials directly to the desired connection point i.e. 
the domain, the credentials information held in the logon 
certificate need not be replicated throughout the distrib- 
uted system and there is no need to establish a direct 
connection back to the domain controller of the home 
domain. Moreover, the logon certificates provide a con- 
venient vehicle for controlling access to the system. Lo- 
gon certificates are revocable and expire after a prede- 
termined period of time. Further, encryption techniques 
are applied to contents of the logon certificate to ensure 
that the contents are secure. 

[0026] Figure 1 is a block diagram of a distributed sys- 
tem 100 that is suitable for practicing the preferred em- 
bodiment of the present invention. Those skilled in the 
art will appreciate that the configuration shown in Figure 
1 is merely illustrative and that the present invention 
may be practiced in other distributed system configura- 
tions. The distributed system 100 of Figure 1 includes 
workstations 101, input/output (I/O) devices 102, net- 
work servers 103 and secondary storage devices 104. 
In addition, the distributed system 100 includes domain 
controllers 106 (which will be described in more detail 
below). 

[0027] The distributed system 100 is logically parti- 
tioned into domains 108A, 108B and 108C. Each do- 
main 1 08A, 1 08B and 1 08C is a self-sufficient collection 
of resources that is viewed as a single entity for purpos- 
es of administration, naming and security. Each domain 
implements its own administrative and security policies. 
Domains are provided to facilitate scaling and encapsu- 
lation of resources into logical units within the distributed 
system. 

[0028] Although the preferred embodiment of the 
present invention utilizes domains, those skilled in the 
art will, nevertheless, appreciate that domains are not a 
necessary component for practicing the present inven- 
tion. The present invention may be practiced in environ- 
ments that do not utilize domains. 
[0029] Each domain 108A, 108B and 108C includes 
at least one domain controller 106. More than one do- 
main controller 1 06 may be provided within a domain so 
as to enhance the availability of domain controller re- 
sources. Each domain controller 106 serves as a cen- 
tralized location for storing knowledge about the name- 
space of the distributed system 100. Among the com- 
ponents included within each domain controller 1 06 are 
an authorization service (AS) 1 07 and an authentication 



service, known as the key distribution center (KDC) 1 09. 
The AS 1 07 is aservice that controls authorization rights 
that are provided to clients and validates requests to 
gain access to servers. A client, in this context, is a proc- 
5 ess that makes use of a network service on behalf of a 
user. The KDC 109 acts as an authentication service in 
that it authenticates the identities of principals. A princi- 
pal is a uniquely named client or server instance. A serv- 
er is a principal that provides a resource to clients. The 
AS 107 and KDC 109 work in conjunction to perform 
authorization and authentication respectively when a 
user wishes to logon to the system 100 and use its re- 
sources. 

[0030] It is helpful to first look at the authentication 
performed during a logon. For each user/machine, the 
user/machine engages in an authentication protocol, 
such as the Kerberos, version 5, release 5 protocol de- 
veloped by the Massachusetts Institute of Technology, 
which will be described in more detail below. For the 
present invention, we are concerned solely with the au- 
thentication that is performed when a user/machine 
seeks to connect to the system outside its home domain. 
Through this protocol, users and machines exhibit 
knowledge of shared secrets that serve as credentials 
that verify the identity of the user/machine. 
[0031] Each domain controller 106 holds information 
about users and machines for which the domain is the 
home domain. The domain controller 106 of a domain 
holds both the authentication credentials and authoriza- 
tion information for each of its users and machines. Lo- 
gon certificates provide a vehicle to demonstrate that 
the user/machine has sufficient credentials to connect 
to the non-home domain without contacting the home 
domain. Thus, a user/machine may freely roam the dis- 
tributed system and connect to all domains where such 
connection is authorized. This approach, however, does 
not require replication of the credentials throughout the 
distributed system, as required by conventional sys- 
tems. 

[0032] The logon certificates may be created in part 
through the use of encryption mechanisms. In particular, 
the logon certificates may be made secure by using an 
asymmetric encryption strategy wherein a public key 
and a private key pair is utilized to encrypt portions of 
the logon certificates. A noteworthy characteristic of an 
asymmetric encryption scheme is that it allows different 
keys for encryption and decryption unlike symmetric en- 
cryption systems that use the same key for both encryp- 
tion and encryption. These keys are referred to as public 
and private key pair. Each domain has an associated 
key pair that includes a public key and a private key that 
are used in encryption as will be described in more detail 
below. The public key is published exclusively to domain 
controllers 1 06 in other domains through a location and 
distribution protocol provided by the KDC 1 09 of the do- 
main controller 106. The publication occurs during do- 
main installation without user involvement. Thus, for in- 
stance, a domain controller 106 in domain 108A pub- 
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lishes its public key to domain controllers 106 in do- 
mains 108B and 108C. So as to enhance the integrity 
of the system, the public keys are only published to the 
domain controllers 1 06 in other domains and not to other 
entities. Hence, the public keys are not made entirely 
public knowledge. The private key, in contrast, is kept 
secret within the domain controller 1 06 of the domain. 
[0033] Figure 2A is a block diagram showing the com- 
ponents of a logon certificate 11 0. A logon certificate 1 1 0 
is a sealed packet that includes a digitally signed and 
sealed certificate of credentials 118, a session key 120 
and, optionally, user or machine specific data 122. The 
logon certificate 110 also contains information such as 
the time the logon certificate was issued, the time of ex- 
piration of the logon certificate and the time at which the 
logon certificate becomes valid (i.e., start time). 
[0034] The digitally signed and sealed certificate 1 1 8 
includes at least (as shown in Figure 2B) a privileged 
attribute certificate (PAC) 124 and another copy of the 
session key 126. The PAC 124 encapsulates authoriza- 
tion information for a user or machine. For instance, a 
user's security ID and the security ID of all the groups 
of which the user is a member are included in the PAC 
for a user, along with other authorization information, 
such as the user's privileges and the like. Only authen- 
tication information for a machine is encapsulated in a 
logon certificate for the machine. In the preferred em- 
bodiment of the present invention, the digitally signed 
and sealed certificate 118 is created by initially gener- 
ating a hash of the contents to be included within the 
digitally signed and sealed certificate. A one-way hash 
function, such as the MD5 hash function proposed by 
Ron Rivest, is used to generate the hash of the contents 
of the digitally signed and sealed certificate 118. A ran- 
dom encryption key is then selected and the data to be 
included in the certificate 1 1 8 is encrypted using the ran- 
domly selected key using a bulk encryption algorithm 
like the RC4 encryption algorithm proposed by Ron 
Rivest. Lastly, a digital signature is created by encrypt- 
ing the pair of the hash and the encryption key together 
by the domain's private key for the domain issuing the 
certificate using an asymmetric encryption algorithm like 
the RSA encryption algorithm. Note that use of MD5, 
RC4, and RSA is not a requisite to practicing this inven- 
tion and comparable algorithms may be substituted for 
these algorithms. 

[0035] The session key 1 26 is a dynamically generat- 
ed key that is particular to a given communications ses- 
sion. The session key may be used to encrypt commu- 
nications during a session between aclient and a server, 
such as between a user's machine and the KDC 109. 
[0036] The logon certificate 110 that includes a ses- 
sion key, a digital signature, a sealed certificate of cre- 
dentials, and other information, like issuing domain, etc., 
is sealed by further encrypting it with a user-supplied 
password. The domain where the logon certificate 110 
is later used will have been a recipient of the public de- 
cryption key that was distributed. If this domain has been 



configured to accept certificates from the issuing do- 
main, it will decrypt the logon certificate in order to re- 
cover its contents. 

[0037] Those skilled in the art will appreciate that the 
5 contents of the logon certificate 110 may include addi- 
tional information or different information from that 
shown in Figures 2A and 2B. The information depicted 
in Figures 2A and 2B constitutes what is included in the 
preferred embodiment of the present invention and is 
10 not intended as a limitation of the scope of the present 
invention as defined in the appended claims. 
[0038] Figure 3 is a flow chart illustrating the basic 
steps involved in using the logon certificates in the pre- 
ferred embodiment of the present invention. The se- 
15 quence of steps is intended to merely be illustrative, and 
the steps may be performed in a different order. More- 
over, all the steps need not be performed to practice the 
present invention. 

[0039] Every time a machine is booted in its home do- 

20 main it obtains a logon certificate 110 from the domain 
controller of its home domain that certifies the identity 
of the machine (step 128). The certificate is obtained 
and issued if and only if machine was able to authenti- 
cate itself to the distributed system. The machine can 

25 later submit the logon certificate 1 1 0 to the domain con- 
troller 106 of another domain to which it is being con- 
nected when the machine boots. Similarly, every time a 
user logs on in his home domain, he obtains a logon 
certificate 1 1 0 from the domain controller 1 06 (step 1 30 

30 in Figure 3). Again, the certificate is issued if and only if 
the user was able to authenticate himself to the distrib- 
uted system. The logon certificate 1 1 0 may then later be 
used to logon at a site in a different domain. The non- 
home domain to which the user is permitted to logon 

35 using the logon certificate 1 1 0 is known as the "connec- 
tion domain" and provides connectivity services to the 
user. 

[0040] A user may request to download the logon cer- 
tificate 110 onto a removal storage media, such as a 

40 floppy diskette. When the user requests to download a 
logon certificate 1 1 0 onto such a removable storage me- 
dia, he is prompted to supply a password. A one-way 
hash function is used to hash this password, which is 
then used to generate an encryption key, which in turn 

45 is used to further encrypt the logon certificate. This pass- 
word is required to prevent any third party that is in pos- 
session of a logon certificate on a removable storage 
media from fraudulently logging on as the user to whom 
the logon certificate was issued. 

50 [0041] Once the machine and user have received lo- 
gon certificates 110, typically, the user tries to boot the 
machine at a remote domain within the distributed sys- 
tem 100. During the boot of the machine at the remote 
domain, the machine submits the logon certificate 110 

55 to the distributed system 1 00 to identify itself and to ver- 
ify that the machine is authorized to be connected to the 
distributed system (step 132 in Figure 3). If the machine 
submits the proper credentials, the machine is then con- 
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nected to the distributed system 1 1 0 (step 1 34). The us- 
er may then logon to the distributed system. As part of 
the logon process (as will be described in more detail 
below), the user submits the logon certificate 110 (step 
136). If the logon certificate 110 indicates that the user 
is an authorized user, the user is permitted to logon and 
use the distributed system (step 138). 
[0042] It should be appreciated that the steps shown 
in the flow chart of Figure 3 3 are for an instance wherein 
the user is carrying a portable machine for logging on at 
a remote domain. There may be instances wherein the 
user, instead, utilizes a machine that is already connect- 
ed to the distributed system 1 00 at a remote domain. In 
such an instance, the user may be required to present 
a logon certificate 110 to logon at the remote domain, 
but there may be no logon certificate on the machine the 
user is using. Alternatively, there may be instances 
wherein a portable computer is used by a user at his 
home domain. In such an instance, the portable compu- 
ter may present a logon certificate 1 1 0 to get connected 
to the distributed system 100 but the user need not 
present such a logon certificate. 
[0043] In order to understand how the logon certifi- 
cates 110 are used in logging on to the distributed sys- 
tem 1 00, it is helpful to review some of the fundamentals 
of the Kerberos protocol. Kerberos uses "tickets" to reg- 
ulate access by clients to servers. A ticket is a data struc- 
ture, such as a record, that holds data like the target 
server name, client name and authorization data, that 
helps a client to authenticate itself to a server. The ticket 
allows a client to receive service from a server. 
[0044] An authenticator is a data structure that in- 
cludes the client's name, time stamp, and may also in- 
clude an optional session key. The authenticator in- 
cludes data that is encrypted in the session key. This 
data evidences that the sender knows the session key. 
Further, the time stamp helps to minimize the time peri- 
od in which an eavesdropper may use a copied ticket 
and authenticator pair. 

[0045] In Kerberos, session keys are used to verify 
the credentials of clients and may also be used to en- 
crypt messages between two parties (e.g., a client and 
a server) during a given communication session. When 
the communication session ends, the session key is de- 
stroyed. The session key is shared only between the two 
parties that utilize it. 

[0046] Kerberos maintains an authentication data- 
base that correlates clients, such as users, with their as- 
sociated secret keys. As was mentioned above, a secret 
key is typically an encrypted password or is derived from 
one using a pre-specified algorithm. This authentication 
database is utilized to retrieve the secret keys of the cli- 
ents as needed during execution of the protocol. 
[0047] As mentioned above, logon certificates 1 1 0 are 
used when a user attempts to logon to the distributed 
system 100. Figure 4A shows a flow chart of the steps 
that are performed in such an instance. The steps of the 
flow chart of Figure 4A will be described below in con- 



junction with the block diagram of the system compo- 
nents shown in Figure 4B (which depicts the major com- 
ponents that play a role in authorizing and authenticat- 
ing the user). When a roaming user attempts to logon, 

5 he is presented with a logon menu that includes an op- 
tion to "logon via certificate." The logon menu is provid- 
ed as part of a local logon process that serves as a client 
for the user. If the user selects this option, he may wish 
to logon utilizing a logon certificate 110 carried on a re- 

10 movable storage media, such as a floppy diskette or use 
the logon certificate stored on the machine he is at- 
tempting to logon from. Thus, in step 140, it is deter- 
mined whether the user is logging on using a certificate 
on a removable storage media or a certificate stored in 

15 the user's machine for the user. If the user decides to 
logon using a logon certificate 110 that is contained on 
a removable storage media, the user must provide the 
downloading password that he was required to enter 
when downloading the certificate onto the removable 

20 storage media and the system verifies that this is the 
correct downloading password (step 142). Failure to 
supply the correct downloading password will prevent 
the user from using the logon certificate 110 stored on 
the removable storage media. If the user wishes to use 

25 the logon certificate stored on the machine (most likely 
the portable computer the user uses often), then he 
must supply his normal logon password. 
[0048] In either case the logon process uses this 
password to generate an encryption key using a pre- 

30 specified and fixed algorithm. It then uses this key to 
decrypt the logon certificate retrieved from either the re- 
movable storage media or the machine itself. The client 
thus obtains an encrypted session key that was stored 
in the encrypted logon certificate and is also stored in 

35 the encrypted block of credentials. The client will use 
this encrypted session key exactly in the way it would 
use the key derived from the user-supplied password in 
case of a normal logon sequence without using logon 
certificate. 

40 [0049] The system initiates an authentication ex- 
change by prompting the user for the user's name and 
password (step 144). The logon process then sends a 
request for a ticket granting ticket (TGT) to KDC 109, 
which runs on a domain controller 106 in the local do- 

45 main (step 146). The logon certificate 110 is sent along 
with the request for TGT. The request for the TGT is rep- 
resented by arrow 168 in Figure 4B. The KDC 109 de- 
termines that the logon request is by a user in some oth- 
er domain and then looks up the public key associated 

50 with the domain specified in the logon certificate. It uses 
this public key to unseal the certificate of credentials and 
verify that the certificate was indeed issued by the do- 
main named in the un-encrypted part of the logon cer- 
tificate 110 and that the logon certificate is valid (i.e. it 

55 has not expired) and that the current time is past the 
start time held in the certificate. The KDC 109 also ob- 
tains the encrypted session key from the sealed certifi- 
cate of credentials 118 and uses it exactly in the same 



6 



11 



EP 0 695 985 B1 



12 



way as it would have used the encryption key derived 
from the one way hash of user's password stored in its 
database for the users it has entries for in its authenti- 
cation database. Once the KDC 1 09 has verified the au- 
thenticity of the certificate 1 1 8 by verifying the digital sig- 
nature and concluded that the certificate is valid (step 
1 48), the KDC 1 09 then sends a TGT and a new session 
key (to be used in further communications) that has 
been encrypted by the session key obtained from the 
sealed certificate, to the client 166 (step 150) as repre- 
sented by arrow 170. 

[0050] The client 166 decrypts the new session key 
sent by the KDC(since the client is in possession of the 
session key from decrypting the logon certificate as de- 
scribed above) and saves the new session key for future 
use (step 152). The client 166 then initiates a request 
for a credentials ticket granting ticket (CTGT) by asking 
the KDC 1 09 for a service ticket to the AS 1 07 (step 1 54). 
The CTGT is used to obtain tickets to servers that re- 
quire the client to provide authorization information. This 
request is represented by arrow 172 in Figure 4B. The 
request includes the TGT that was received earlier from 
the KDC 109. 

[0051 ] The KDC 1 09 receives the request from the cli- 
ent 1 66 and responds to the request by returning a ticket 
for the AS 1 07 to the client 1 66 that includes the digitally 
signed and sealed certificate 118 (step 156). The send- 
ing of the ticket to the AS 107 is represented by arrow 
174 in Figure 4B. 

[0052] The client 166 then requests a PAC from the 
AS 107. This PAC will eventually be incorporated into 
the CTGT that is ultimately issued to the client 1 66 (step 
1 58). The request is represented by arrow 1 76 in Figure 
4B. The AS 1 07 normally accesses an authorization da- 
tabase to obtain authorization information. However, in 
the present instance, since the user is logging on using 
a logon certificate, the user is outside his home domain, 
and thus, the authorization database holds no informa- 
tion about the user. Thus, to provide the PAC, the AS 
107 uses the domain's public key to decrypt the digital 
signature and thus, obtains the symmetric key used for 
encrypting the certificate of credentials and the hash val- 
ue of its contents. The AS 107 decrypts the certificate 
of credentials and recomputes the hash of decrypted 
contents and that must match the hash value obtained 
from the digital signature. Having verified this and also 
ascertaining the validity of other aspects of certificate, 
the AS 107 prepares a PAC from the contents of the 
digitally signed and sealed certificate 1 1 8 in the ticket to 
craft user's rights and privileges. The AS 1 07 also marks 
this PAC as the one generated via logon certificate, a 
fact that can be used by the local security policy of the 
target domain. Those skilled in the art will appreciate the 
fact that the AS 107 can augment the contents of the 
PAC with additional privileges or restrictions. It then 
seals the PAC with the secret key that it shares with the 
KDC before returning it to the client. The PAC is sealed 
by encrypting it with the secret key of the KDC 109 so 



that the client cannot access it. The AS 1 07 returns the 
sealed PAC (note arrow 178 in Figure 4B) to the client 
166 (step 160). 

[0053] The client 166 sends a message to the KDC 

5 109, along with the sealed PAC (note arrow 180 in Fig- 
ure 4B) to get a CTGT from the KDC (step 162). The 
KDC 1 09 generates the CTGT so as to include the PAC 
and forwards (note arrow 182 in Figure 4B) the CTGT 
to the client (step 148). The CTGT contains the IDs for 

10 the user, the privileges of the user, group memberships 
of the user, and is sealed by encryption using the secret 
key of the PS. At this juncture, the user appears as if he 
had an account in the domain to which he is connected. 
If the user wishes to access a server, he may use his 

15 TGT or CTGT. 

[0054] When a machine is initially booted and is con- 
nected to the distributed system 100, the above steps 
beginning with step 129 are repeated. The machine 
takes the place of the user in these steps. Thus, the ma- 

20 chine may be validated as a proper machine to be part 
of the distributed system 1 00. 

[0055] As mentioned above, logon certificates 1 1 0 are 
both revocable and expirable. As to the expirable nature 
of the logon certificates 110, each certificate includes a 

25 start time at which it becomes valid and an expiration 
time at which it becomes invalid. In order for a logon 
certificate 1 1 0 to be valid, the start time of the logon cer- 
tificate must have already been reached and the expi- 
ration time of the logon certificate 1 1 0 must not yet have 

30 been reached. 

[0056] A logon certificate 110 is revocable and may 
be explicitly revoked. When an account is inactivated or 
an administrator instructs the system to revoke logon 
certificates 1 1 0, the domain controller 1 06 of the issuing 

35 domain circulates a message that lists all user IDs hav- 
ing their logon certificates revoked. This message is 
signed by the private key of the issuing domain. Other 
domain controllers 106 utilize this message to deter- 
mine which parties requesting logon have sufficient cre- 

40 dentials. In some instance, it may be necessary for a 
domain to change its public and private keys and prop- 
agate the new public and private key to other domain 
controllers 106. As a result, the existing logon certifi- 
cates 110 issued by the domain are no longer valid. 

45 [0057] It should be appreciated that each domain con- 
troller 1 06 can mark certain resources within the domain 
that are to be accessible to visitors that logon via logon 
certificates 110. A special account may be provided 
within the namespace of the domain to handle such vis- 

50 itors. 



Claims 

55 1. A method for authenticating and authorizing princi- 
pals in a distributed system (100) having computer 
resources (101, 103) and a facility (107, 109) for 
checking credentials information to authenticate 
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principals and provide with authorization data, com- 
prising steps for: 

providing (130) a principal with a secure pack- 
age (110) holding credentials information for a 5 
client (166); 

receiving a principal request (136) to connect 
to the distributed system at a location in the dis- 
tributed system (1 00) that lacks credentials in- 10 
formation about the principal to gain access to 
at least some of the computing resources; 

accessing the credentials information held in 
the secure package (1 1 0) to enable the facility 15 
(107, 109) for checking credentials information 
to determine whether the principal is authorized 
and authenticated to be connected to the dis- 
tributed system (1 00) without obtaining creden- 
tials information about the principal from a 20 
source other than the secure package (110); 

where the principal is not authorized or not authen- 
ticated to connect to the distributed system (100), 
denying the principal request to be connected to the 25 
distributed system (100); and 
where the principal is authorized and authenticated 
to connect to the distributed system (1 00), granting 
the principal request (138) to be connected to the 
distributed system (1 00). 30 

2. The method of claim 1 wherein the principal is a us- 
er. 

3. The method of claim 1 wherein the distributed sys- 35 
tern (100) is logically partitioned into domains 
(108A-108C), each user having an associated 
home domain, and wherein the step of providing 
(130) a user with a secure package (110) holding 
credentials information for a client comprises: 40 

encrypting credentials about the user to pro- 
duce a block (118) of encrypted credentials in- 
formation; 

45 

attaching a digital signature to the block (118) 
of encrypted credentials information at the 
home domain of the user using a private key for 
the home domain; 

50 

receiving a session key (120) from the user; 
and 

encrypting the digital signature and the block 
(118) of encrypted credentials information to 55 
produce a secure package (110). 

4. The method of claim 3 wherein the step of attaching 



the digital signature to the block (1 1 8) of encrypted 
credentials information further comprises the steps 
of: 

using a hash function to generate a hash value 
of the credentials information and other data 
like expiration time; 

selecting an encryption key; 

encrypting the hash value and selected encryp- 
tion key using the domain's private key to pro- 
duce the digital signature. 

5. The method of claim 3 or 4 wherein each domain 
(1 08A-1 08C) includes a domain controller (1 06) for 
overseeing administration and security for the do- 
main (1 08A-1 08C) and wherein the step of encrypt- 
ing credentials information about the user is per- 
formed using an encryption key that is unique to the 
home domain. 

6. The method of claim 5, further comprising the step 
of distributing the public key of the user's home do- 
main only to other domain controllers (1 06) for use 
in decrypting the block (118) of encrypted creden- 
tials information. 

7. The method of claim 1 wherein the principal is a 
portable computer. 

8. The method of claim 1 wherein the distributed sys- 
tem includes a portable computer having memory 
and the step of providing (1 30) the principal with the 
secure package (110) holding credentials informa- 
tion for the client (1 66) into the memory of the port- 
able computer. 

9. The method of one of the claims 1 to 8 wherein the 
step of providing (130) the principal with the secure 
package (110) holding credentials information for 
the client (166) further comprises a step of storing 
the secure package (11 0) on a portable storage me- 
dium. 

10. The method of claim 9 wherein the portable storage 
medium is a floppy disk and the step of storing the 
secure package (110) on the portable storage me- 
dium comprises a step of storing the secure pack- 
age (110) on the floppy disk. 

1 1 . The method of claim 1 wherein the step of providing 
(130) the principal with the secure package (110) 
holding credentials information for the client (166) 
comprises a step of providing the principal with an 
encrypted package holding credentials information 
for the client (166). 
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von einer anderen Quelle als dem Sicherheits- 
paket (110) zu beschaffen; 

wenn das Subjekt nicht autorisiert oder nicht 
5 authentifiziert ist, Verbindung mit dem verteil- 

ten System (100) aufzunehmen, Ablehnen der 
Subjekt-Anforderung, mit dem verteilten Sy- 
stem (100) Verbindung aufzunehmen; und 

10 wenn das Subjekt autorisiert und authentifiziert 

ist, mit dem verteilten System (1 00) Verbindung 
aufzunehmen, Stattgeben der Subjekt-Anfor- 
derung (138), mit dem verteilten System (100) 
Verbindung aufzunehmen. 

15 

2. Verfahren nach Anspruch 1 , wobei das Subjekt ein 
Nutzer ist. 

3. Verfahren nach Anspruch 1 , wobei das verteilte Sy- 
20 stem (100) logisch in Domanen (108A-108C) parti- 

tioniert ist, wobei jeder Nutzer eine zugehorige 
Heimdomane hat, und wobei der Schritt des Aus- 
stattens (1 30) eines Nutzers mit einem Sicherheits- 
paket (1 1 0), das Berechtigungsinformationen fur ei- 
25 nen Client enthalt, umfasst: 



12. The method of claim 1 wherein the step of providing 
(130) the principal with the secure package (110) 
holding credentials information for the client (166) 
comprises a step of providing a digitally signed and 
sealed package (118) holding credentials informa- 
tion for a user of the distributed system (100). 

13. The method of claim 1 wherein determining whether 
the principal is authenticated to be connected to the 
distributed system (100) comprises the steps of: 

determining whether the secure package (110) 
is authentic; and 

where the secure package (110) is determined to 
be authentic, determining that the principal is au- 
thenticated to be connected to the distributed sys- 
tem (100). 

14. A computer program comprising computer execut- 
able instructions adapted to perform the steps of the 
method according to one of the claims 1 to 13. 

15. A computer readable medium having instructions 
thereon for performing the computer program ac- 
cording to claim 14. 



Patentanspruche 

1. Verfahren zum Authentifizieren und Autorisieren 
von Subjekten in einem verteilten System (100), 
das Computerressourcen (101, 103) und eine Ein- 
richtung (107, 109) aufweist, mit der Berechti- 
gungsinformationen gepruft werden, urn Subjekte 
zu authentifizieren und mit Autorisierungsdaten zu 
versehen, das die folgenden Schritte umfasst: 

Ausstatten (130) eines Subjekts mit einem Si- 
cherheitspaket (110), das Berechtigungsinfor- 
mationen fur einen Client (166) enthalt; 

Empfangen einer Subjekt-Anforderung (136) 
zur Aufnahme von Verbindung mit dem verteil- 
ten System an einer Position in dem verteilten 
System (1 00), die keine Berechtigungsinforma- 
tionen uber das Subjekt aufweist, urn Zugang 
zu wenigstens einigen der Computerressour- 
cen zu erhalten; 

Zugreifen auf die Berechtigungsinformationen, 
die in dem Sicherheitspaket (110) enthalten 
sind, urn die Einrichtung (1 07, 1 09) in die Lage 
zu versetzen, Berechtigungsinformationen zu 
prufen, urn festzustellen, ob das Subjekt auto- 
risiert und authentifiziert ist, mit dem verteilten 
System (100) Verbindung aufzunehmen, ohne 
Berechtigungsinformationen uber das Subjekt 



Verschlusseln von Berechtigungsinformatio- 
nen uberden Nutzer, urn einen Block (11 8) ver- 
schlusselter Berechtigungsinformationen zu 
30 erzeugen; 

Anhangen einer digitalen Signatur an den 
Block (118) verschlusselter Berechtigungsin- 
formationen in der Heimdomane des Nutzers 
35 unter Verwendung eines privaten Schlussels 

fur die Heimdomane; 

Empfangen eines Sitzungsschlussels (120) 
von dem Nutzer; und 

40 

Verschlusseln der digitalen Signatur und des 
Blocks (118) verschlusselter Berechtigungsin- 
formationen, urn ein Sicherheitspaket (110) zu 
erzeugen. 

45 

4. Verfahren nach Anspruch 3, wobei der Schritt des 
Anhangens der digitalen Signatur an den Block 
(118) verschlusselter Berechtigungsinformationen 
des Weiteren die folgenden Schritte umfasst: 

50 

Verwenden einer Hash-Funktion, urn einen 
Hash-Wert der Berechtigungsinformationen 
und andere Daten, wie beispielsweise die Ab- 
laufzeit, zu erzeugen; 

55 

Auswahlen eines Verschlusselungsschlussels; 
Verschlusseln des Hash-Wertes und des aus- 
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gewahlten Verschlusselungsschlussels unter 
Verwendung des privaten Schlussels der Do- 
mane, um die digitale Signatur zu erzeugen. 

5. Verfahren nach Anspruch 3 oder 4, wobei jede Do- 5 
mane (108A-108C) einen Domanen-Controller 

(1 06) enthalt, der die Verwaltung und die Sicherheit 
fur die Domane (1 08A-1 08C) uberwacht, und wobei 
der Schritt des Verschlusseins von Berechtigungs- 
informationen uber den Nutzer unter Verwendung 10 
eines Verschlusselungsschlussels ausgefuhrt wird, 
der allein der Heimdomane zugeordnet ist. 

6. Verfahren nach Anspruch 5, das des Weiteren den 
Schritt des Verteilens des offentlichen Schlussels 15 
der Heimdomane des Nutzers nur an andere Do- 
manen-Controller (106) zur Nutzung beim Ver- 
schlusseln des Blocks (118) verschlusselter Be- 
rechtigungsinformationen umfasst. 

20 

7. Verfahren nach Anspruch 1 , wobei das Subjekt ein 
tragbarer Computer ist. 

8. Verfahren nach Anspruch 1 , wobei das verteilte Sy- 
stem einen tragbaren Computer mit einem Speicher 25 
enthalt und der Schritt des Ausstattens (130) des 
Subjektes mit dem Sicherheitspaket (1 1 0), das Be- 
rechtigungsinformationen fur den Client (166) ent- 
halt, einen Schritt des Speicherns des Sichemeits- 
paketes (1 00) in dem Speicher des tragbaren Com- 30 
puters umfasst. 

9. Verfahren nach einem der Anspruche 1 bis 8, wobei 
der Schritt des Ausstattens (1 30) des Subjektes mit 
dem Sicherheitspaket (110), das Berechtigungsin- 35 
formationen fur den Client (166) enthalt, des Wei- 
teren einen Schritt des Speicherns des Sicherheits- 
paketes (100) auf einem tragbaren Speichermedi- 

um umfasst. 

40 

10. Verfahren nach Anspruch 9, wobei es sich bei dem 
tragbaren Speichermedium um eine Diskette han- 
delt und der Schritt des Speicherns des Sicherheits- 
pakets (110) auf dem tragbaren Speichermedium 
einen Schritt des Speicherns des Sicherheitspake- 45 
tes (110) auf der Diskette umfasst. 

11. Verfahren nach Anspruch 1, wobei der Schritt des 
Ausstattens (130) des Subjektes mit dem Sicher- 
heitspaket (110), das Berechtigungsinformationen 50 
fur den Client (1 66) enthalt, einen Schritt des Aus- 
stattens des Subjektes mit einem verschlusselten 
Paket umfasst, das Berechtigungsinformationen fur 
den Client (166) enthalt. 

55 

12. Verfahren nach Anspruch 1, wobei der Schritt des 
Ausstattens (130) des Subjektes mit dem Sicher- 
heitspaket (110), das Berechtigungsinformationen 



fur den Client (166) enthalt, einen Schritt des Be- 
reitstellens eines digital signierten und verschlos- 
senen Paketes (118) umfasst, das Berechtigungs- 
informationen fur einen Nutzer des verteilten Sy- 
stems (100) enthalt. 

13. Verfahren nach Anspruch 1 , wobei die Feststellung, 
ob das Subjekt authentifiziert ist, mit dem verteilten 
System (1 00) Verbindung aufzunehmen, die folgen- 
den Schritte umfasst: 

Feststellen, ob das Sicherheitspaket (110) au- 
thentisch ist, und 

wenn festgestellt wird, dass das Sicherheitspa- 
ket (110) authentisch ist, Feststellen, dass das 
Subjekt authentifiziert ist, mit dem verteilten 
System (100) Verbindung aufzunehmen. 

14. Computerprogramm, das durch Computer ausfuhr- 
bare Befehle umfasst, mit denen die Schritt des Ver- 
fahrens nach einem der Anspruche 1 bis 1 3 ausge- 
fuhrt werden konnen. 

15. Computerlesbares Medium, das Befehle zum Aus- 
fuhren des Computerprogramms nach Anspruch 1 4 
darauf aufweist. 



Revendications 

1. Procede pour authentifier et autoriser des entites 
dans un systeme de traitement reparti (100) com- 
portant des ressources informatiques (101, 1 03) et 
des moyens (107, 109) pour verifier les informa- 
tions d'habilitation pour authentifier des entites et 
fournir des donnees d'autorisation, le procede com- 
prenant les etapes consistant a : 

fournir (130) a une entite un module securise 
(110) contenant des informations d'habilitation 
pour un client (166) ; 

recevoir d'une entite une demande (136) de 
connexion au systeme de traitement reparti en 
un emplacement du systeme de traitement re- 
parti (1 00) qui ne comporte pas les informations 
d'habilitation concernant I'entite pour I'acces a 
au moins certaines des ressources 
informatiques ; 

acceder aux informations d'habilitation conte- 
nues dans le module securise (110) pour per- 
mettre aux moyens (1 07, 1 09) servant a verifier 
les informations d'habilitation de determiner si 
I'entite a I'autorite et I'authentification requises 
pour etre connectee au systeme de traitement 
reparti (100) sans obtenir des informations 
d'habilitation au sujet de I'entite a partir d'une 
source autre que le module securise (110) ; 
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lorsque I'entite n'a pas I'autorisation ou n'a pas 
I'authentification requises pour etre connectee 
au systeme de traitement reparti (100), rejeter 
la demande de connexion au systeme de trai- 
tement reparti (100) faite par I'entite ; et 
lorsque I'entite a I'autorisation et I'authentifica- 
tion requises pour etre connectee au systeme 
de traitement reparti (1 00), accepter la deman- 
de (138) de connexion au systeme de traite- 
ment reparti (100) faite par I'entite. 

2. Procede selon la revendication 1 , dans lequel I'en- 
tite est un utilisateur. 

3. Procede selon la revendication 1, dans lequel le 
systeme de traitement reparti (100) est divise logi- 
quement en domaines (108A a 108C), chaque uti- 
lisateur ayant un domaine personnel associe, et 
dans lequel I'etape de fourniture (130) a un utilisa- 
teur d'un module securise (1 1 0) contenant les infor- 
mations d'habilitation pour un client consiste a : 

crypter I'habilitation concernant I'utilisateur 
pour produire un bloc (1 1 8) d'informations d'ha- 
bilitation cryptees ; 

adjoindre une signature numerique au bloc 
(118) d'informations d'habilitation cryptees au 
niveau du domaine personnel de I'utilisateur 
utilisant une cle privee pour le domaine 
personnel ; 

recevoir de I'utilisateur une cle de session 
(120) ; et 

crypter la signature numerique et le bloc (118) 
d'informations d'habilitation cryptees pour pro- 
duire un module securise (110). 

4. Procede selon la revendication 3, dans lequel I'eta- 
pe d'adjonction de la signature numerique au bloc 
(118) d'informations d'habilitation cryptees com- 
prend les etapes consistant a : 

utiliser une fonction de hachage pour generer 
une valeur de hachage des informations d'ha- 
bilitation et autres donnees comme la date 
d'expiration, 

selectionner une cle de cryptage ; 
crypter la valeur de hachage et la cle de cryp- 
tage selectionnee en utilisant la cle privee du 
domaine pour produire la signature numerique. 

5. Procede selon la revendication 3 ou la revendica- 
tion 4, dans lequel chaque domaine (1 08A a 1 08C) 
comprend un dispositif de commande de domaine 
(106) servant a surveiller ('administration et la se- 
curity concernant le domaine (108A a 108C) et 
dans lequel I'etape de cryptage des informations 
d'habilitation relatives a I'utilisateur est executee en 
utilisant une cle de cryptage qui est unique au do- 



maine personnel. 

6. Procede selon la revendication 5, comprenant, en 
outre, I'etape consistant a distribuer la cle publique 
5 du domaine personnel de I'utilisateur uniquement a 

d'autres dispositifs de commande de domaine (1 06) 
dans le but de decrypter le bloc (11 8) d'informations 
d'habilitation cryptees. 

10 7. Procede selon la revendication 1 , dans lequel I'en- 
tite est un ordinateur portable. 

8. Procede selon la revendication 1, dans lequel le 
systeme de traitement reparti comprend un ordina- 
ls teur portable comportant une memoire et I'etape 

consistant a fournir (130) a I'entite le module secu- 
rise (110) contenant les informations d'habilitation 
pour le client (166) dans la memoire de I'ordinateur 
portable. 

20 

9. Procede selon I'une des revendications 1 a 8, dans 
lequel I'etape de fourniture (130) du module secu- 
rise (110) contenant les informations d'habilitation 
pour le client (166) comprend, en outre, une etape 

25 consistant a stocker le module securise (110) dans 
un support de memoire portable. 

10. Procede selon la revendication 9, dans lequel le 
support de memoire portable est un disque souple 

30 et I'etape consistant a stocker le module securise 
(110) dans le support de stockage portable com- 
prend une etape consistant a stocker le module se- 
curise (110) dans le disque souple. 



35 11. Procede selon la revendication 1 , dans lequel I'eta- 
pe consistant a fournir a I'entite le module securise 
(110) contenant les informations d'habilitation pour 
le client (166) comprend une etape consistant a 
fournir a I'entite un module crypte contenant les in- 

40 formations d'habilitation pour le client (1 66). 

12. Procede selon la revendication 1 , dans lequel I'eta- 
pe consistant a fournir (130) a I'entite le module se- 
curise (110) contenant les informations d'habilita- 

45 tion pour le client (166) comprend une etape con- 
sistant a fournir un module scelle et signe de fagon 
numerique (1 1 8) contenant les informations d'habi- 
litation pour un utilisateur du systeme de traitement 
reparti (100). 

50 

1 3. Procede selon la revendication 1 , dans lequel la de- 
termination concernant I'authentification de I'entite 
en vue de sa connexion au systeme de traitement 
reparti (100) comprend les etapes consistant a : 

55 

determiner si le module securise (110) est 
authentique ; et 

lorsque I'etape de determination etablit que le 
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module securise (110) est authentique, deter- 
miner que I'entite a I'authentification requise 
pour etre connectee au systeme de traitement 
reparti (100). 

5 

14. Programme informatique comprenant des instruc- 
tions executables par ordinateur concues pour exe- 
cuter les etapes du procede selon I'une quelconque 
des revendications 1 a 13. 

10 

15. Support lisible par ordinateur comportant des ins- 
tructions permettantd'executer le programme infor- 
matique selon la revendication 14. 
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